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Abstract 

Military  and  humanitarian  missions  increasingly  involve 
not  only  the  participation  of  one  nation  but  of  forces  al¬ 
lied  in  a  coalition.  Real-time  information  exchange  is  in¬ 
disputably  a  critical  aspect  required  for  the  success  of  these 
missions.  The  requirement  for  interoperability  between  de¬ 
ployed  information  management  systems  is  not  restricted  to 
overcoming  the  low  level  obstacles  in  data  exchange  result¬ 
ing  from  diverse  information  systems.  The  rising  challenge 
is  the  selection  and  control  of  the  content  shared  with  coali¬ 
tion  partners.  Which  coalition  partner  needs  to  be  included 
in  operational  information?  How  is  it  assured  that  in  a 
changing  situation  all  affected  partners  are  alerted?  Cur¬ 
rently,  this  management  of  information  exchange  is  accom¬ 
plished  by  Information  Management  Officers  (IMO),  who 
manually  sift  through  all  incoming  operational  data  and 
piece  by  piece  discern  what  information  needs  to  be  shared 
and  with  whom.  The  information  base,  however,  has  in¬ 
creased  over  time  to  the  point  that  the  IMO  is  being  over¬ 
loaded. 

The  Coalition  Secure  Management  and  Operations  Sys¬ 
tem  ( COSMOS)  Advanced  Concept  Technology  Demonstra¬ 
tion  (ACTD)  was  designed  to  help  assist  in  the  process  of 
managing  coalition  information  exchange  and  interoper¬ 
ability.  Through  the  use  of  an  ontology  driven  architecture, 
COSMOS  is  able  to  represent  operational  data  with  mean¬ 
ingful  relationships  and  thus  allows  intelligent,  autonomous 
software  agents  to  reason  about  the  needs  of  information 
exchange  and  assist  the  IMO  in  the  decision  making  pro¬ 
cess.  This  information  sharing  is  accomplished  through 
the  use  of  role-based  Information  Exchange  Requirements 
(IER)  which  are  individually  assigned  by  the  IMO  and  are 
specific  to  the  roles  played  by  each  coalition  member  within 
the  context  of  the  overall  mission.  Agents,  intelligent  ex¬ 
pert  system  software  modules,  are  utilized  to  assist  in  the 
process  of  managing  IER  assignment  and  the  assessment 
of  information  against  the  criteria  which  formalize  the  IER 
definition.  It  is  through  this  process  that  information  ex¬ 


change  is  targeted  to  the  coalition  force  components  that 
have  a  specific  requirement  for  information  pertaining  to 
their  assigned  roles. 
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1.  Overview 

1.1.  Background 

The  Coalition  Secure  Management  and  Operations  Sys¬ 
tem  (COSMOS)  Advanced  Concept  Technology  Demon¬ 
stration  (ACTD)  provides  a  venue  to  show  how  Command 
and  Control  (C2)  information  can  be  shared  within  a  coali¬ 
tion  C2  environment  while  retaining  security  of  data  ex¬ 
change  as  dictated  by  individual  member-nation  doctrine. 
Secure  information  exchange  is  demonstrated  through  em¬ 
ployment  of  formal  rule  declaration  as  defined  by  specific 
Tactics,  Techniques,  and  Procedures  (TTP)  governing  the 
dissemination  of  relevant  information  “to  the  right  place  at 
the  right  time”  based  on  assigned  operational  roles  and  task¬ 
ing  [1]. 

The  management  of  information  exchange  is  naturally 
complex  although  employment  of  computer  software  tools 
can  be  effectively  applied  to  aid  in  the  processes  governing 
the  controlled  exchange  of  information.  The  human  factor 
plays  an  important  role;  fully  automated  information  shar¬ 
ing  is  neither  practical  nor  desirable.  Thus,  the  COSMOS 
ACTD  seeks  to  demonstrate  capabilities  that  assist  (but  do 
not  replace)  the  Information  Management  Officer  (IMO)  in 
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managing  C2  information  exchange  across  coalition  bound¬ 
aries. 

Employment  of  computer  software  tools,  within  the 
domain  of  controlled  C2  information  exchange,  requires 
machine-level  understanding  of  the  information  exchange 
process.  This  includes  detailed  understanding  of  the  struc¬ 
ture  of  the  C2  information  domain  as  well  as  the  procedures 
utilized  in  managing  the  process.  The  structural  represen¬ 
tation  of  information  can  be  readily  defined  in  terms  of  an 
information  model  that  captures  detailed  characteristics  as 
well  as  explicit  relationships  inherent  between  information 
entities.  In  development  for  over  twenty  years  through  the 
Multilateral  Interoperability  Programme  (MIP),  a  standard 
data  model  in  the  form  of  the  Command  and  Control  In¬ 
formation  Exchange  Data  Model  (C2IEDM)  exists  and  has 
been  accepted  within  a  multi-national  consortium  within  the 
NATO  community  [2].  This  data  model  offers  the  means 
for  representing  information  in  a  highly  structured  form 
that  lends  itself  well  as  the  basis  for  software-based  anal¬ 
ysis.  The  COSMOS  ACTD  has  chosen  the  C2IEDM  as 
the  basis  for  development  and  demonstration  of  capabili¬ 
ties  employed  to  aid  in  the  management  of  the  information 
exchange  process.  Along  with  the  C2IEDM,  MIP  has  de¬ 
fined  a  specific  Data  Exchange  Mechanism  (DEM),  within 
a  formal  specification,  that  may  be  utilized  in  the  exchange 
of  data.  By  utilizing  C2IEDM  and  the  DEM,  COSMOS 
has  demonstrated  controlled,  secure  information  exchange 
within  a  data  exchange  environment  which  is  currently  es¬ 
tablished  and  deployed  in  the  coalition  C2  enterprise. 

1.2.  Shortfall  Addressed 

The  MIP  DEM  specification  describes  the  protocols  and 
processes  necessary  for  managing  the  exchange  of  C2  data 
as  defined  by  the  C2IEDM.  The  specification  also  describes 
a  fairly  general  data  filter  mechanism.  This  mechanism  may 
be  used  to  limit  the  exchange  of  data  to  only  that  which  sat¬ 
isfies  explicit  filter  criteria.  However,  the  specification  de¬ 
fines  these  filters  based  on  low-level  data  constraints  which 
do  not  easily  translate  to  Information  Exchange  Require¬ 
ments  (IER).  Therefore,  an  additional  capability  is  required 
to  translate  or  interpret  high-level  IERs  into  these  low-level 
data  filters.  Additionally,  the  DEM  provides  the  facility  for 
utilizing  Operational  Information  Groups  (OIGs)  as  the  ba¬ 
sis  for  a  contractual  agreement  for  the  exchange  of  infor¬ 
mation  between  coalition  C2  system  nodes.  Information  in¬ 
cluded  in  specific  OIGs  can  be  targeted  for  exchange  with 
other  MIP-compliant  C2  nodes  based  on  negotiated  con¬ 
tracts  tied  to  these  OIGs.  Other  than  implied  high-level 
information  categories,  these  OIGs  do  not  employ  specific 
rules  governing  constraint  of  information  content.  The  com¬ 
bination  of  low-level  data  filters  and  use  of  OIGs  provides 


the  basis  for  specific  control  of  information  exchange.  The 
addition  of  higher-level  tools,  such  as  those  proposed  by 
the  COSMOS  Information  Management  Officer’s  (IMO) 
Toolkit,  would  provide  the  required  interfacing  elements  to 
allow  effective  use  of  the  MIP  DEM  in  the  control  of  infor¬ 
mation  exchange  based  on  criteria  intuitive  to  the  function 
of  the  IMO  (e.g.,  definition  of  IERs  as  applied  to  operational 
roles  and  tasking). 

1.3.  Functional  Requirements 

The  COSMOS  Information  Management  Tool  (IMT)  re¬ 
quirements  are  centered  around  the  overarching  require¬ 
ment  for  managing  the  information  exchange  process. 
These  requirements  include  creation,  management,  mon¬ 
itoring,  and  controlling  information  sharing  agreements. 
These  requirements,  in  turn,  suggest  a  set  of  capabilities 
that  augment  (but  do  not  necessarily  replace)  the  informa¬ 
tion  exchange  management  processes.  For  instance,  the  use 
of  role  assignment  to  operational  units  to  provide  a  link 
to  information  requirements  provides  the  facility  for  creat¬ 
ing  and  managing  sharing  agreements.  The  IMT  interface 
would  provide  the  required  interface  allowing  for  Informa¬ 
tion  Management  Officer  (IMO)  interaction  with  role  defi¬ 
nition  in  terms  of  information  exchange  requirements.  Ad¬ 
ditionally,  this  tool  is  required  to  archive  this  information 
for  later  retrieval  and  use  during  operations.  The  manage¬ 
ment  of  sharing  agreements  during  planning,  training,  and 
operational  use  is  facilitated  through  the  use  of  the  IMT  and 
the  pre-defined  sharing  agreements  in  the  form  of  the  op¬ 
erational  role  and  associated  information  exchange  require¬ 
ments.  Additionally,  the  IMT  is  required  to  provide  report¬ 
ing  facilities  to  give  access  and  control  over  the  information 
exchange  process  through  a  view  into  the  data  exchange  fil¬ 
ters  and  contracts  established  as  a  result  of  operational  role 
assignment.  A  key  requirement  for  the  COSMOS  IMT  is 
to  provide  direct  IMO  interaction  in  the  exchange  process 
through  monitoring  and  controlling  sharing  agreements.  In 
other  words,  even  though  the  IMT  facilitates  the  informa¬ 
tion  exchange  process  through  automated  exchange  control, 
the  tool  is  not  a  “black  box”  and  must  include  the  user  (in 
this  case,  the  IMO)  in  the  decision  making  process. 

1.4.  Enabling  Capabilities 

A  principal  enabling  technology  for  providing  collabo¬ 
rative  decision  support  is  the  employment  of  a  high-level 
information  representation  and  the  implicit  framework  re¬ 
quired  to  support  management  and  interaction  with  the  On¬ 
tology.  Services  developed  to  support  specialized  informa¬ 
tion  domains  provide  required  capabilities  in  the  form  of 
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discrete  software  modules.  These  capabilities  include  sup¬ 
port  for  agent/user  interaction  through  object-oriented  in¬ 
terfaces  reflecting  the  information  structure  as  defined  by 
the  Ontology.  Common  services  are  available  to  support 
asynchronous  access,  persistent  storage,  information  map¬ 
ping,  and  knowledge  inference  (such  as  might  be  required 
by  software  agents). 

Additionally,  a  distributed  information  management 
framework  provides  flexibility  in  system  deployment 
through  run-time  configuration  without  requiring  software 
modification.  Some  level  of  platform  independence  is  also 
inherent  in  such  a  framework  -  in  other  words,  the  abil¬ 
ity  to  deploy  across  a  distributed  network  is  facilitated  by 
platform-independent  capabilities.  A  distributed  informa¬ 
tion  management  framework  also  enables  development  of 
discrete  software  modules  in  the  form  of  services  and  appli¬ 
cations.  Although  not  necessarily  inherent,  a  highly  desir¬ 
able  feature  of  a  truly  distributed  information  management 
infrastructure  is  the  notion  of  location  transparency  which 
simply  provides  for  information  access  without  requiring 
any  knowledge  of  the  underlying  information  management 
functionality.  In  other  words,  information  can  be  accessed 
by  services  and  applications  without  any  concern  or  knowl¬ 
edge  about  where  the  information  is  physically  managed. 

1.5.  Ontology-Based  Solution  with  Agents 

The  principal  objective  of  COSMOS  is  to  provide  US 
and  coalition  forces  with  a  secure  and  reliable  capability 
for  sharing  the  right  information  at  the  right  time  with  the 
right  forces.  The  solution  that  COSMOS  provides  is  built 
on  the  internationally  recognized  C2IEDM  data  structure. 
It  extends  this  data  model  with  an  ontology  that  provides 
the  necessary  context  for  software  agents  to  automatically 
reason  about  battlespace  events  and  assist  the  Information 
Management  Officer  (IMO)  with  the  expeditious  policy- 
driven  exchange  of  information  in  a  cross-domain  environ¬ 
ment. 

The  ontology  approach  is  the  enabler  of  all  COSMOS 
capabilities  and  is  therefore  the  essential  core  component 
of  the  distributed,  service-oriented  COSMOS  architecture. 
Without  the  ontology  component  the  cross-domain  secu¬ 
rity  capabilities  of  COSMOS  could  not  be  exercised  by  the 
IMO  at  the  level  of  data  granularity  that  is  required  for  the 
effective  exchange  of  data.  More  specifically,  without  an 
object-oriented  internal  ontology  representation  the  COS¬ 
MOS  software  would  not  be  able  to  anticipate  that  a  given 
force  or  unit  will  immediately  or  in  the  near  future  require 
the  exchange  of  certain  information  to  effectively  perform 
its  mission  or,  for  example,  to  prevent  a  potential  fratricide 
situation.  Without  such  ontology/agent-based  capabilities  it 


would  all  be  left  to  the  human  operator  (i.e.,  the  IMO)  who 
is  likely  to  be  overwhelmed  by  data  and  may  not  recognize 
this  particular  data  exchange  requirement  until  it  becomes  a 
crisis. 

From  a  slightly  more  technical  point  of  view: 

•  A  key  aspect  that  COSMOS  provides  over  and  above 
MIP  is  the  concept  of  controlled-managed  information 
exchange. 

•  Inherent  in  the  control  of  information  exchange  is 
knowledge  of  both  the  natural  structure  of  the  informa¬ 
tion  being  exchanged  as  well  as  the  logic  and  concepts 
that  comprise  the  process  used  to  manage  information 
exchange. 

•  The  ontology  approach  provides  a  mechanism  for  for¬ 
mally  defining  an  information  structure  (e.g.,  an  object 
model)  that  includes  the  complex  relationships  that  are 
part  of  information  that  describes  real  world  knowl¬ 
edge  (i.e.,  the  context  within  which  data  changes  can 
be  interpreted  and  analyzed). 

•  Information  that  describes  knowledge  within  the  Com¬ 
mand  and  Control  (C2)  domain  is  formally  defined 
by  the  C2IEDM  data  model,  which  is  part  of  the 
MIP  specification.  C2IEDM  can  be  represented  us¬ 
ing  an  ontological  approach  and  the  latter  is  in  fact 
provided  in  this  underlying  data  structure  as  part  of 
the  MIP  specification.  However,  MIP  does  not  pro¬ 
vide  a  detailed  model  that  defines  the  elements  and 
concepts  that  are  required  to  explicitly  control  the  in¬ 
formation  exchange.  MIP  does  provide  a  Data  Ex¬ 
change  Mechanism  (DEM)  that  loosely  defines  a  pro¬ 
tocol  for  establishing  contracts  (i.e.,  agreements  to  ex¬ 
change  data)  based  on  Operational  Information  Groups 
(OIG).  OIGs,  within  the  MIP  specification,  are  not 
constrained  in  a  way  that  allows  for  explicit  control 
of  the  information  contained  within  them  and  hence 
has  no  formal  mechanism  for  controlling  information 
exchange. 

•  Without  ontologies,  it  would  be  necessary  to  employ 
software  tools  that  encapsulate  the  logic  required  to 
assess  the  C2  state  and  implicitly  constrain  informa¬ 
tion  containment  in  specialized  OIGs.  Traditional  ap¬ 
proaches  would  hard  code  this  logic  into  the  software 
tools  with  internal  information  constructs  (also  hard 
coded)  employed  to  simplify  the  coding  logic.  The  on¬ 
tology  approach  provides  a  formal  means  of  describing 
these  traditionally  embedded  constructs  in  a  form  that 
is  directly  presentable  in  terms  that  make  sense  to  the 
user.  Additionally,  logic  captured  in  this  form  can  be 
readily  used  by  software  agents  as  a  basis  for  their  au¬ 
tomated  reasoning  capabilities. 
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•  The  use  of  ontologies  and  software  agents  provides  a 
formalized  definition  of  the  information  and  logic  used 
to  manage  the  information  exchange  process.  Because 
of  this  formal  definition  it  is  possible  to  utilize  tools 
and  generic  infrastructures  to  build  and  manage  a  sys¬ 
tem  that  implements  the  capabilities  required  to  sup¬ 
port  the  information  exchange  management  process. 
Additionally,  this  approach  provides  a  basis  for  evolv¬ 
ing  a  system  and  its  capabilities  as  new  requirements 
arise  without  incurring  significant  development  costs. 
Capabilities  may  be  added  by  simply  extending  the 
ontology  and  adding  agent  logic  (as  additional  agent 
modules)  with  minor  user  interface  development. 

•  With  the  ontology  approach,  separate  ontologies  may 
be  employed  to  address  problem  domains  requiring 
specialized  services.  This  offers  significant  flexibility 
in  the  deployment  and  operation  of  the  system.  For  ex¬ 
ample,  a  separate  security  domain  may  be  developed 
in  the  form  of  an  ontology  and  agents  utilizing  the 
tools  for  constructing  the  requisite  information  infras¬ 
tructure.  Also,  security  management  and  monitoring 
functions  require  specialized  operating  environments 
that  allow  access  to  sensitive  areas  of  the  information 
management  environment  and  as  such  require  deploy¬ 
ment  within  a  secure  network  environment.  By  uti¬ 
lizing  discrete  ontologies  and  agents  within  a  frame¬ 
work  supporting  distribution  of  the  constructed  ser¬ 
vices,  it  is  possible  to  meet  the  requirement  for  sup¬ 
porting  both  the  management  of  the  information  ex¬ 
change  and  the  information  security.  That  is  not  to 
say  that  this  would  not  be  possible  utilizing  other  ap¬ 
proaches,  however,  the  use  of  ontologies  and  agents 
does  provide  the  means  for  more  easily  extending  and 
maintaining  these  capabilities  (i.e.,  it  is  simply  just 
good  software  engineering  and  design  practice). 


2.  Architecture 


2.1.  System  Architecture 


Figure  1  shows  the  overall  system  architecture  for  the 
COSMOS  IMT.  In  this  architecture,  the  Ontology  domains 
represent  the  common  knowledge  infrastructure  over  which 
all  clients  within  the  IMT  operate.  It  is  important  to  note 
that  user  interfaces,  agents,  and  the  interoperability  bridge 
all  communicate  through  this  common  knowledge  infras¬ 
tructure.  The  components  that  make  up  the  IMT  architec¬ 
ture  will  be  presented  in  more  detail. 


2.2.  Physical  Architecture 

Figure  2  shows  the  physical  components  and  interfaces 
that  comprise  the  COSMOS  IMT.  Each  of  the  domains, 
which  were  highlighted  in  the  system  architecture  (Figure 
1),  are  shown  in  more  detail  to  illustrate  that  each  domain 
has  its  own  set  of  services  that  manage  its  content.  The 
black  arrows  indicate  dependencies  which  all  eventually 
lead  back  to  the  Ontology  domain  models.  In  other  words, 
the  infrastructure  built  to  management  the  knowledge  bases 
are  all  driven  by  the  respective  Ontology  domain  models. 
Additionally,  note  that  client  applications  -  especially  the 
user  interface,  agents,  and  interoperability  bridge  -  all  op¬ 
erate  through  the  object  management  layer  which,  in  turn, 
provides  access  to  all  knowledge  domains  present  in  the 
system.  Also  recognize  that  in  this  framework  all  clients 
that  interact  with  the  knowledge  base  do  so  through  a  com¬ 
mon  interface  and  that  all  the  details  contained  in  the  man¬ 
agement  of  the  information  are  hidden  from  these  clients. 
They  simply  interact  with  objects  as  defined  by  the  respec¬ 
tive  Ontology  domain  model.  Another  important  aspect  of 
this  architecture  is  the  services  that  provide  the  underlying 
infrastructure.  In  particular,  the  subscription  service  pro¬ 
vides  for  an  asynchronous  query-like  mechanism  that  al¬ 
lows  clients  to  register  for  interests  based  on  query  criteria 
with  notification  upon  satisfaction  of  those  interests.  Inter¬ 
ests  are  registered  in  terms  of  the  domain  model  and  are, 
therefore,  also  tied  to  the  natural  information  structure  de¬ 
fined  by  the  Ontology. 

2.3.  Components 
Information  Services 

The  Ontology  infrastructure  provides  the  common  informa¬ 
tion  conduit  through  which  all  components  interact.  The 
information  structure  presented  by  the  Ontology  reflects  the 
structure  defined  by  the  individual  domain  models  in  which 
each  model  is  a  partitioning  of  the  overall  Ontology  into 
logical  information  category  groupings. 

Interoperability  Bridge 

The  IMT  Bridge  uses  an  Interoperability  Bridge  Frame¬ 
work  as  a  solution  to  transfer  information  between  a 
MIP-compliant  system  and  the  COSMOS  IMT  application. 
The  Interoperability  Bridge  Framework  provides  a  generic 
framework  for  seamless  interaction  and/or  integration  of 
multiple  heterogeneous  systems.  Systems  can  register  ser¬ 
vices  with  the  Interoperability  Bridge,  publish  local  system 
requests  and  responses,  and  receive  remote  requests  and  re¬ 
sponses  without  knowing  intimate  details  about  the  remote 
system. 
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XML  is  sent  (either  by  notifications  or  request  mecha¬ 
nisms)  from  each  application  in  its  native  format  and  trans¬ 
lated  by  the  bridge  based  on  remote  requests.  Remote  re¬ 
quests  are  brokered  by  the  bridge  to  a  remote  system  that 
can  service  that  request.  Information  published  to  the  bridge 
is  in  the  XML  format  of  the  native  system,  usually  in  the 
format  of  the  local  application’s  specific  domain  (such  as 
the  C2  domain).  Translators  can  be  configured  to  trans¬ 
form  the  XML  messages  from  a  given  remote  system  to 
native  system  format.  While  the  framework  supports  mul¬ 
tiple  translation  formats,  the  main  translation  format  of  the 
bridge  is  XSLT  (Extensible  Stylesheet  Language  Transfor¬ 
mation).  XSLT  provides  an  XML-centric  means  to  translate 
XML  between  multiple  schemas. 


Agent  Engine 

The  Agent  Engine  is  an  autonomous  software  client  that  in¬ 
teracts,  independently  of  other  clients,  with  the  COSMOS 
system.  The  word  autonomous  is  used  purposely,  as  no  di¬ 
rect  human  interaction  with  the  Agent  Engine  occurs.  Once 
launched,  the  Agent  Engine  monitors  the  system,  through 
the  use  of  subscriptions,  for  specific  patterns  and  classes  of 
objects.  When  these  patterns  are  met,  action  is  taken,  most 
often  in  the  form  of  alerts  or  observations.  These  alerts 
or  observations  are  then  posted  to  the  COSMOS  system 
where  the  GUI  client  component  picks  them  up  and  dis¬ 
plays  them  for  the  Information  Management  Officer  (IMO). 
This  logic,  or  pattern  matching,  is  carried  out  through  the 
use  of  agents.  An  agent  is  considered  to  be  a  very  spe¬ 
cific  goal  orientated  software  module.  Currently,  the  COS¬ 
MOS  Agent  Engine  is  loaded  with  three  (3)  agents:  The 
Unit  Capability  (UC)  Agent,  the  Information  Exchange  Re¬ 
quirements  (IER)  Agent,  and  the  Exchange  Control  (EC) 
Agent.  The  UC  Agent  is  responsible  for  monitoring  Unit 
Weapon  Capabilities  and  alerting  the  IMO  when  these  ca¬ 
pabilities  change.  The  IER  Agent  watches  for  new  Tasks 
to  be  created  and  alerts  the  IMO  that  he  may  need  to  create 
IERs  to  share  information  with  coalition  partners.  The  last 
agent,  the  EC  Agent,  is  responsible  for  information  sharing 
to  coalition  forces,  based  on  the  IERs  that  the  IMO  creates. 
Currently  the  IMO  is  being  overburdened  and  bombarded 
with  too  much  information.  These  agents  work  indepen¬ 
dently  of  each  other  and  are  designed  to  assist  the  IMO  by 
reducing  and  streamlining  the  workload. 


User  Interface 

The  COSMOS  IMT  User  Interface  constitutes  a  central 
component  of  the  COSMOS  Information  Management  Tool 
(IMT),  a  suite  of  applications  which  together  provide  the  ca¬ 
pability  for  managing  the  process  of  information  exchange 
across  Command  and  Control  (C2)  system  boundaries. 


COSMOS  IMT  information  exchange  management  ca¬ 
pabilities  include  the  creation,  management,  monitoring, 
and  control  of  information- sharing  agreements.  Specifi¬ 
cally,  the  use  of  role  or  task  assignment  to  operational  units 
provides  a  link  to  information  requirements,  the  basis  for 
creating  and  managing  sharing  agreements. 

The  IMT  user  interface  allows  for  Information  Manage¬ 
ment  Officer  (IMO)  interaction  with  role-  and  task-based 
information  sharing  agreements  that  are  defined  in  terms  of 
Information  Exchange  Requirements  (IER). 

2.4.  Interfaces 

Data  Service  Layer  (DSL)  Interface 

The  DSL  C2IEDM  Object  Service  interface  provides  a  view 
into  the  command  and  control  (C2)  domain  whose  con¬ 
tent  is  managed  through  the  MIP  and  a  C2IEDM-compliant 
database.  This  interface  provides  a  read-only  view  provid¬ 
ing  only  a  subset  of  the  total  command  and  control  picture 
as  required  for  managing  the  information  exchange  process. 
Based  on  the  requirements  of  the  IMO  and  the  IMT  agents, 
interest  subscriptions  are  established  on  the  C2  domain  and 
are  reflected  through  the  interoperability  bridge  and  its  con¬ 
nector  to  the  DSL  C2IEDM  Object  Service  interface.  Only 
the  information  that  satisfies  those  interest  criteria  will  be 
reflected  back  through  the  interface  and  in  the  C2  Ontology 
domain  within  the  IMT. 

Data  Exchange  Mechanism  (DEM)  Interface 

The  DEM  interface  provides  access  to  information  ex¬ 
change  management  contracts  and  COSMOS  Information 
Group  (CIG)  assignments.  The  Extensible  Markup  Lan¬ 
guage  (XML)  is  used  as  the  protocol  language  for  informa¬ 
tion  interchange  through  the  interoperability  bridge  connec¬ 
tor.  Through  the  DEM  interface,  CIG  assignments  are  af¬ 
fected  by  IMT  interactions  (whether  through  IMO  or  agent 
initiation).  Information  defined  within  the  Exchange  Con¬ 
trol  domain  within  the  IMT  will  map  to  the  management 
information  used  within  the  DEM.  In  other  words,  when  ei¬ 
ther  the  IMO  (through  the  user  interface)  or  agents  affect 
information  in  the  Exchange  Control  domain,  that  informa¬ 
tion,  in  turn,  will  map  directly  to  the  DEM  through  the  in¬ 
teroperability  bridge  and  this  DEM  interface. 
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3.  Design/Implementation 

3.1.  Command  and  Control  (C2)  Domain 
Model 

Figure  3  shows  a  very  small  subset  of  the  complete  C2 
Ontology  domain,  and  only  serves  to  illustrate  the  model 
representation  as  presented  in  the  form  of  the  Unified  Mod¬ 
eling  Language  (UML).  As  published  by  the  MIP,  the 
C2IEDM  is  formally  specified  in  terms  of  an  Entity  Rela¬ 
tionship  model  which,  in  turn,  may  be  used  to  directly  con¬ 
struct  a  database  schema  suitable  for  managing  data  con¬ 
strained  to  the  structure  of  the  C2IEDM.  However,  to  ef¬ 
fectively  utilize  information  reflecting  this  structure,  within 
the  IMT  architecture,  it  was  necessary  to  provide  a  model 
in  terms  of  UML.  From  the  UML  model,  the  C2  domain 
services  may  then  be  generated  utilizing  model  processing 
code  generation  tools. 

3.2.  Exchange  Control  Domain  Model 

The  exchange  control  domain,  a  portion  of  which  is 
shown  in  Figure  4,  defines  objects  that  are  used  to  affect 
the  process  of  information  exchange.  Key  concepts,  defined 
within  the  exchange  control  domain,  include  the  notion  of  a 
collaborator  as  an  initiator  and  performer  of  actions,  where 
actions  are  initiated/performed  events  that  have  time  and 
duration.  Kinds  of  collaborators  include  agents  and  C2  ob¬ 
jects.  In  this  domain  model  C2  objects  shadow  object  items 
in  the  C2  domain  and  serve  to  specifically  represent  those 
entities  that  can  play  roles  in  actions  -  for  example,  mili¬ 
tary  units.  The  notion  of  a  node  is  also  represented  as  a 
collaborator  so  that  systems  themselves  can  be  represented 
as  participating  in  actions  (e.g.,  data  exchange  contracts). 
Kinds  of  actions  include  contract  and  information  exchange 
actions.  Additionally,  information  groups  are  represented  as 
groups  constrained  by  information  exchange  requirements. 
Information  groups  in  the  exchange  control  domain  also 
shadow  information  groups  defined  in  the  C2  domain  -  for 
example  operational  information  groups  (OIG).  Represen¬ 
tation  for  constraints  is  included  to  provide  definition  of 
action  triggers.  Providing  such  action  trigger  definitions 
implies  that  if  a  constraint  is  matched  then  the  associated 
action  will  be  triggered.  Area  constraints  are  specifically 
represented  as  constraints  tied  to  geophysical  areas.  Cri¬ 
teria  are  defined  as  a  kind  of  constraint  that  groups  other 
constraints  using  a  logical  operator.  Criteria  may  be  used  to 
build  reasonably  complex  constraints.  For  example,  an  area 
constraint  may  be  defined  and  associated  to  an  information 
exchange  action  with  the  implied  exchange  triggered  if  the 
area  constraint  condition  is  satisfied.  It  should  be  noted  that 


this  complex  behavior  (action  triggering)  is  only  implied  by 
the  model  definition  of  criteria  -  it  is  through  employment  of 
agents  (software  modules  providing  information  inference) 
that  this  behavior  is  actually  implemented.  In  fact  it  is  the 
logic  embedded  in  the  Exchange  Control  agent  (introduced 
previously)  that  provides  the  assessment  function  to  deter¬ 
mine  the  triggering  of  an  information  exchange  action  based 
on  criteria  satisfaction. 

The  combined  Ontology  diagram,  shown  in  Figure  5,  il¬ 
lustrates  the  connection  between  the  Exchange  Control  and 
C2  domains.  Specifically,  through  a  one-way  associations, 
the  exchange  control  C2Item  class  shadows  the  C2IEDM 
Objectltem  class  and  the  InformationGroup  class  shadows 
the  C2IEDM  OperationallnformationGroup.  Since  these 
are  one-way  relationships,  only  the  exchange  control  do¬ 
main  requires  knowledge  of  the  C2  domain.  There  is  no 
requirement  for  C2  domain  entities  to  refer  back  to  or  have 
any  knowledge  of  exchange  control  entities. 

Information  entities  defined  within  the  Exchange  Con¬ 
trol  domain  have  been  described  as  “shadowing”  elements 
defined  within  the  C2  domain.  Specifically,  elements  in  the 
Exchange  Control  domain  are  defined  to  reflect  information 
contained  in  the  C2  domain  in  a  form  that  is  more  read¬ 
ily  assessed  for  the  purpose  of  managing  information  ex¬ 
change.  These  elements  are  simply  facades  [3,  4]  whose 
features  are  derived  from  information  gathered  from  C2  do¬ 
main  elements.  A  simple  example  is  shown  in  figure  4.  The 
C2Item  location  features  (latitude,  longitude)  are  derived 
from  the  associated  C2  Object  Item  Location  (shown  in  fig¬ 
ure  5)  which,  if  defined  specifically  as  an  Absolute  Point 
(a  kind  of  Location  defined  in  C2IEDM),  contains  features 
defining  the  absolute  latitude  and  longitude  coordinates  of 
the  associated  Object  Item.  This  derived  location  simply  re¬ 
flects  the  values  defined  in  the  referenced  C2  domain  entity. 
It  is  through  use  of  these  uni-directional  associations  and 
derived  features  that  enables  effective  extension  of  the  C2 
domain  without  directly  affecting  it’s  structure. 

3.3.  Agents 

The  Agent  Engine  is  a  Java-based  client  that  connects 
to  the  COSMOS  IMT  system.  Its  main  purpose  is  to  aid 
the  IMO  by  assisting  in  the  management  of  the  information 
exchange  process  (through  the  use  of  agents).  The  Agent 
Engine  is  responsible  for  managing  the  agents  and  directing 
information  to  and  from  them  at  the  appropriate  time. 

Abstractly,  an  agent,  as  represented  within  the  Agent  En¬ 
gine,  is  a  software  module  dedicated  to  perform  a  specific 
task  or  series  of  tasks.  The  agent  looks  at  the  attributes  of 
objects,  either  in  one  object  or  many  objects,  and  if  certain 
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patterns  or  conditions  are  met,  the  agent  executes  the  task 
or  set  of  tasks. 

Specifically,  an  agent  within  the  COSMOS  IMT  is  rep¬ 
resented  as  an  object  within  the  Exchange  Control  Object 
Model.  When  the  agent  is  loaded  into  the  Agent  Engine, 
an  instance  of  the  Agent  class  is  created  and  posted  to  the 
COSMOS  IMT  system  for  other  clients  to  utilize.  As  with 
the  Agent  Engine,  all  current  agents  are  written  in  Java  and 
utilize  the  Java  Bean  pattern  to  receive  creation,  modifica¬ 
tion,  and  deletion  events  on  objects.  These  events  are  facil¬ 
itated  through  the  use  of  subscriptions.  The  Agent  Engine 
can  set  up  specific  event  listeners  so  that  it  receives  only  the 
information  that  its  agents  need. 

For  the  COSMOS  IMT,  we  have  3  primary  agents:  the 
Exchange  Control  Agent,  the  Information  Exchange  Re¬ 
quirements  Agent,  and  the  Unit  Capability  Agent.  Each 
agent  operates  independently  and  toward  a  unique  objec¬ 
tive.  In  the  following  sub- sections,  each  agent  is  further 
defined  and  exemplified. 


Unit  Capability  Agent 

The  Unit  Capability  Agent  is  responsible  for  monitoring  all 
Units  and  their  weapons.  When  the  agent  detects  that  a  Unit 
is  given  a  Weapon  with  a  Fire  Capability,  it  will  create  a  cir¬ 
cular  Area  of  Influence  (AOI)  around  the  Unit  equal  to  the 


maximum  firing  range  of  that  weapon.  As  the  Unit  receives 
and  removes  weapons  from  its  arsenal,  the  agent  will  always 
keep  track  of  the  farthest  reaching  weapon,  and  its  AOI  will 
always  reflect  this  farthest  reaching  range.  The  agent  will 
also  keep  track  of  the  weapon’s  operational  quantity  so  that 
if  it  has  fired  all  of  its  rounds,  is  damaged,  etc.,  the  agent 
will  remove  the  weapon  and  utilize  the  next  farthest  reach¬ 
ing  operational  weapon  as  the  AOI  and  its  radius  will  be 
adjusted  as  appropriate.  If  there  are  no  other  operational 
weapons  that  have  a  maximum  firing  range,  then  the  AOI  is 
removed  for  that  Unit  as  it  no  longer  has  an  Area  of  Influ¬ 
ence. 


Information  Exchange  Requirements  Agent 

The  Information  Exchange  Requirements  (IER)  Agent  is  re¬ 
sponsible  for  alerting  the  IMO  that  a  new  Task  has  entered 
the  system.  Tasks  and  their  requirements  are  the  heart  of  the 
COSMOS  system.  It  is  through  unit  task  assignment,  and 
the  details  that  define  these  tasks,  that  information  require¬ 
ments  may  be  inferred,  thereby,  suggesting  information  be 
shared  between  coalition  nodes  to  facilitate  successful  op¬ 
erational  task  completion.  The  IER  Agent  prompts  the  IMO 
to  create  Information  Exchange  Requirements  for  Tasks  tied 
to  specific  coalition  partners. 
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Exchange  Control  Agent 

The  Exchange  Control  Agent  is  responsible  for  deciding 
and  automating  the  addition  and  subtraction  of  information 
from  Information  Groups,  ultimately  determining  what  is 
shared  out  to  other  COSMOS  nodes  that  have  contracts  to 
receive  information  within  the  Information  Groups.  This 
agent  capitalizes  on  the  work  done  by  the  Information  Ex¬ 
change  Requirements  (IER)  Agent  and  IMO.  The  Exchange 
Control  Agent  monitors  all  Object  Items  (Tracks,  Platforms, 
Control  Features,  etc.)  and  checks  to  see  if  any  of  them 
meet  the  criteria  created  by  the  IMO  through  the  IER  Agent. 
If  a  piece  of  information  meets  the  criteria  put  forth  on  an 
IER,  then  the  Exchange  Control  Agent  will  add  this  piece 
of  information  to  the  coalition  partner-specific  information 
group  on  which  the  IER  was  defined.  Once  this  piece  of 
information  is  added  to  the  group,  the  Exchange  Control 
Agent  continues  to  monitor  it  for  updates.  If,  at  any  time, 
the  piece  of  information  changes  to  the  extent  that  it  no 
longer  satisfies  all  the  criteria  defined  on  the  group,  then 
the  Exchange  Control  Agent  will  remove  it  from  the  group 
and  post  a  new  observation  for  the  IMO. 

4.  Conclusion 

The  COSMOS  IMO  Tool  provides  a  framework  de¬ 
signed  to  assist  the  IMO  in  the  process  of  managing  the  con¬ 
trolled  exchange  of  C2  information  in  the  coalition  interop¬ 
erability  operational  environment.  The  framework  utilizes 
architectural  (e.g.,  Service- Oriented,  Model-Driven)  ele¬ 
ments  that  enable  development  of  domain  specific  services 
through  employment  of  model  processing  tools  and  basic 
information  management  infrastructure.  The  interface  pre¬ 
sented  through  the  framework  provides  an  object-oriented 
view  of  the  underlying  information  structure  allowing  soft¬ 
ware  modules  to  be  developed  accessing  information  based 
on  it’s  natural  structure  without  requiring  knowledge  of  the 
information  management  functions.  The  IMO  Tool  system 
suite  includes  agents  (software  modules)  whose  logic  is  de¬ 
veloped  based  purely  on  the  process  of  managing  informa¬ 
tion  exchange  captured  from  subject- area  experts.  Addi¬ 
tionally,  these  services  and  software  modules  are  decoupled 
processes  that  may  be  deployed  across  a  heterogeneous  net¬ 
work  of  computers.  It  is  through  the  combination  of  these 
technologies  that  the  system  comprising  the  COSMOS  IMO 
Tool  is  able  to  provide  the  required  functional  elements  for 
secure  information  exchange  in  the  coalition  C2  network 
environment  and  enable  future  extension. 
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A.  Glossary 

Agent  A  software  entity  capturing  domain  logic/expertise 
(behavior  and  semantics).  Provides  feedback  in  re¬ 
sponse  to  satisfaction  of  logical  conditions  to  enable 
collaborative  decision  support. 

Contract  An  agreement  between  two  nodes,  established 
during  the  planning  stage,  to  share  information  con¬ 
tained  in  specific  CIGs.  A  single  contract  only  defines 
information  sharing  in  one  direction  (from  the  provider 
to  the  requester). 

Command  And  Control  (C2)  The  exercise  of  authority 
and  direction  by  a  properly  designated  commander 
over  assigned  and  attached  forces  in  the  accomplish¬ 
ment  of  a  mission.  Command  and  Control  functions 
are  performed  through  an  arrangement  of  personnel, 
equipment,  communication,  facilities,  and  procedures 
employed  by  a  commander  in  planning  directing,  co¬ 
ordinating,  and  controlling  forces  and  operations  in  the 
accomplishment  of  the  mission. 

C2  Information  Exchange  Data  Model  (C2IEDM)  MIP 

prescribed  data  model  structured  to  support  exchange 
of  C2  information  between  MIP  compliant  systems. 

Data  Exchange  Mechanism  (DEM)  MIP  specification 
describing  the  protocols  and  processes  necessary  for 
managing  the  exchange  of  C2  data  as  defined  by  the 
C2IEDM. 

Information  Exchange  Requirement  (IER)  The  basic 
definition  of  a  specific  kind  of  information  required 
to  perform  a  particular  activity  or  function.  The 
requirement  specification  may  be  associated  with  one 
or  more  conditions  that,  when  satisfied,  trigger  an 
appropriate  information  exchange  action. 

Information  Management  Officer  (IMO)  The  user  of  the 
IMT.  Node  -  A  national  entity  capable  of  sharing  op¬ 
erational  information  with,  and  receiving  shared  oper¬ 
ational  information  from,  other  nodes. 

Ontology  A  High-level  information  representation  that  de¬ 
fines  structural  hierarchy,  characteristics,  and  relation¬ 
ships  (i.e.  object  model)  as  well  as  inherent  behavior 
and  semantics  (i.e.  logic). 

Operational  Information  Group  (OIG)  A  coarse  grained 
information  group,  defined  as  one  of  seven  static  OIG 
types  directly  defined  in  the  C2IEDM. 

Role  Activity  or  function  assumed  by  an  operational  unit. 
May  be  used  to  establish  an  entity  fulfilling  a  particular 
role  with  its  basic  set  of  information  requirements. 


Unit  Military  organization  that  can  assume  roles  and  pos¬ 
sess  capabilities  and  assigned  actions. 

B.  Author  Biographies 

Russell  Leighton 

Educational  Background 

M.S.,  Engineering  Mechanics,  The  University  of  Texas 
at  Austin,  1993 

B.S.,  Aeronautical  Engineering,  1984 

Professional  Background 

CDM  Technologies,  Inc.,  San  Luis  Obispo,  CA 
May  1997  -  Present 

Mr.  Leighton  is  the  lead  for  a  technical  development 
team  focused  on  providing  support  for  a  number  of  projects 
targeting  development  of  knowledge  management  and  de¬ 
cision  support  capabilities  in  the  area  of  military  command 
and  control.  Mr.  Leighton  is  currently  serving  in  the  capac¬ 
ity  of  lead  software  engineer  responsible  for  development 
of  the  Coalition  Secure  Operations  and  Management  Sys¬ 
tem  (COSMOS)  Information  Management  Tool  (IMT). 

Air  Force  Rocket  Propulsion  Laboratory  /  Phillips  Lab¬ 
oratory,  Edwards  AFB,  CA 
June  1981  -  May  1997 

Mr.  Leighton’s  work  responsibilities  included  struc¬ 
tural  analysis  of  the  propellant,  case  and  bond  systems  for 
various  solid  propellant  rocket  motors.  Additionally,  Mr. 
Leighton  was  responsible  for  in-house  and  management  of 
contractor  development  of  software  supporting  solid  rocket 
structural  analysis. 

Joshua  Undesser 

Educational  Background 

B.S.,  Electrical  Engineering,  Iowa  State  University  , 
Ames,  2000 

Professional  Background 

CDM  Technologies  Inc,  San  Luis  Obispo,  CA 
July  2000  -  Present 

Mr.  Undesser  is  a  Software  Engineer  whose  main  fo¬ 
cus  has  been  in  the  design  and  development  of  autonomous 
agent-based  decision-support  systems.  Two  more  notable 
projects  that  he  has  been  involved  in  are  IMMACCS  (In¬ 
tegrated  Marine  Multi-Agent  Command  and  Control  Sys¬ 
tem),  which  helps  Marine  commanders  make  time-critical 
decisions,  and  COSMOS  (Coalition  Secure  Management 
and  Operations  System)  which  helps  facilitate  intelligent  in¬ 
formation  sharing  between  coalition  partners. 


11 


TECHNOLOGIES,  INC. 


Ontology  Based  Information  Exchange  Management 
System  for  Secure  Coalition  Interoperability 


21  May  2008 

AFCEA-GMU  “Critical  Issues  in  C4I” 
Interoperability:  Interoperating  Collaborative  Applications 

Russell  Leighton 
Joshua  Undesser 
CDM  Technologies,  Inc. 


Background 


C/Z>As7 

TECHNOLOGIES,  INC. 


•  Coalition  Secure  Management  and  Operations  System 
(COSMOS) 

-  Multilateral  Interoperability  Programme  (MIP) 

•  Command  and  Control  Information  Exchange  Data  Model 
(C2IEDM) 

•  Data  Exchange  Mechanism  (DEM) 

-  Constrained  Information  Exchange  Based  on  Role 

•  Information  Exchange  Requirements  (IER) 

•  Constraint  Model  for  Concise  IER  Definition  and 
Assessment 


Background 
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•  COSMOS  Primary  Objectives 

-  To  provide  an  acceptable  level  of  security  to  the  MIP  data 
exchange  environment 

-  To  reduce  the  volume  of  data  that  currently  flows  through  MIP 
nodes 

-  To  allow  Information  Management  Officers  to  tailor  the  data 
exchange  at  a  finer  level  of  granularity 

-  To  explore  the  potential  capabilities  and  limitations  of  agent 
technology  at  higher  levels  of  security  control 


Enabling  Technologies 
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•  Knowledge  Management  Framework 

-  Service  Oriented  Architecture 

-  Collaborative  decision-support  (agents  and  users) 

-  High-level  information  representation  (ontology) 

-  Common  services  (distributable  software  modules/reuse) 

•  Distributed  Information  Management 

-  Modular  service  and  de-coupled  applications  allow  flexibility 
in  system  deployment  (platform  independence) 

-  Information  location  transparency 

•  System  Interoperability 

-  Access  any  information  domain  using  structured  data  format 

-  Information  mapping  to  alternative  views 


Foundational  Concepts 
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•  Ontology  -  High  level  information  representation  defining  structural 
hierarchy,  characteristics,  and  relationships  (object  model)  as  well  as  inherent 
behavior  and  semantics  (logic). 

•  Agent  -  Software  entity  capturing  domain  logic/expertise  (behavior  and 
semantics).  Provides  feedback  in  response  to  satisfaction  of  logical 
conditions  enabling  collaborative  decision  support. 

•  Information  Exchange  Requirement  (IER)  -  Basic  definition  of  a  specific 
kind  of  information  required  to  perform  a  particular  activity  or  function.  The 
requirement  specification  may  be  associated  with  one  or  more  conditions  that 
when  satisfied  trigger  an  appropriate  information  exchange  action. 

•  Role  -  Activity  or  function  assumed  by  an  operational  unit.  May  be  used  to 
establish  an  entity  fulfilling  a  particular  role  with  its  basic  set  of  information 
requirements. 


Key  Processes 
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•  Define  Role/Task  Information  Requirements 

-  Select  IER  criteria  based  on  pre-defined/similar  roles  or  tasks 

-  Define/modify  IER  criteria  composed  of  information  value 
constraints  (patterns) 

•  Assess  Information  Exchange  Requirements 

-  Evaluate  national  C2  information  against  coalition  exchange 
requirements 

-  Recommend  exchange  of  information  satisfying  IER  criteria  through 
inclusion  in  relevant  Information  Group 

•  Monitor  Information  Exchange 

-  Provide  reports  on  node/contract/group  activity 

-  Validate  incoming  information  against  exchange  requirements 


System  Architecture 
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System  Architecture 
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System  Architecture 
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Interoperability  Bridge: 

•  Provides  information  mapping  service  with  connections  to 
DEM  and  DSL  service  interfaces 
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System  Architecture 
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System  Architecture 
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Agent  Engine 


User  Interface: 

•  Provides  IMO  interaction  functionality 
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System  Architecture 
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DSL  C2IEDM  Object  Service: 

•  Connects  to  IMT  via  the  Interoperability  Bridge 

•  Provides  C2  operational  information  to  IMT 
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System  Architecture 
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DEM  Interface: 

•  Connects  to  IMT  through  Interoperability  Bridge 

•  Provides  DEM  management  information  to  IMT 
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Physical  Architecture 
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Derived  Features 
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references 

Objectltem 

(from  C2 1  ED  M)  I  retOb  jec  t  lie  m 


•  referenceld  ->  refObjectltem. referenced 

•  location  ->  getLocation(refObjectltem...LongitudeCoordinate, 

refObjectltem...LatitudeCoordinate) 

•  country  ->  getCountry(refObjectltem...GeopoliticalCode) 

•  affiliation  ->  getAffiliation(refObjectltem...HostilityStatusCode) 

•  symbol  ->  getSymbolCode(self.affiliation,  self.country) 
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Agents 


Agents 
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IER  Agent  -  Based  on  detected  changes  to  a  unit’s  tasking,  the  agent 
responds  by  recommending  definition  of  Information  Exchange 
Requirement  (IER)  criteria  reflecting  task  information  requirements. 
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•  Knowledge  Representation 

-  Standard  C2  Information  Exchange  Model 

-  Exchange  Control  Model  Incorporating  Specialized  Information 
Perspective  and  Information  Exchange  Constraint 

•  Ontology  Driven  Framework 

-  Generated  Information  Management  Framework 

-  Collaborative  Agents  and  User  Interface 

•  Service  Oriented  Architecture 

-  Information  Management  Services  (Persistence,  Subscription, 
Life-Cycle  Management) 

-  Distributed  Software  Modules 


